第一章 软件测试背景
描述软件失败术语
缺点 defect
偏差 variance
谬误 fault
失败 failure
问题 problt
矛盾 incosistency
错误 error
特殊 feature
毛病 incident
缺陷 bug
异常 anomaly
只要符合以下5个规则才能叫软件缺陷：
软件末达到产品说明书标明的功能
软件出现了产品说明书指明不会出现的错误
软件功能超出产品说明书指明范围
软件末达到产品说明书虽末指出但应达到的目标
软件测试员认为软件难以理解、不易使用、运动速度缓慢、或者最终用户认为不好
导致软件缺陷的最大原因是产品说明书，其次是设计方案，再是编程错误
把软件的试验版分发给小部分客户进行使用，这叫beta测试
软件测试员的目标是发现软件缺陷，作为软件测试员，不能满足于找到软件缺陷–而应该考虑如何在开发过程中尽快地找到软件缺陷，以便降低修复成本。
最终定义–软件测试员的目标是找出软件缺陷，尽可能早一些，并确保其得以修复
大多数软件测试员应具备的素质：
探索精神
故障排除能手
不懈努力
创造性
追求完美
判断准确
老练稳重
说服力
第二章 软件开发过程
产品说明书
进度表
常用软件涉及文档清单：
构架
数据流示意图
状态变化示意图
流程图
注释代码
测试提供内容清单：
测试计划
测试案例
软件缺陷报告
归纳、统计和总结
软件产品不仅限于代码
下面的清单不按次序地列出了主要人员及其职责。给出了最常用的名称
项目管理员、程序管理员或者监制人自始至终驱动整个项目，通常负责编写产品说明书、管理进度、进行重大决策和取舍
设计师或者系统工程师是软件小组的技术专家，一般经验丰富，可以胜任设计整个系统架构或软件构思。他们与程序员关系紧密
程序员、开发人员或者代码制作者设计、编写并修复软件中的缺陷。与项目管理员和设计师密切合作生产软件，然后与项目管理员和测试员密切合作修复缺陷
测试员和质量评判员负责找出并报告软件产品的问题。与小组全部成员在开发过程中密切合作，进行测试并报告发现的问题
技术作者、用户助手、用户培训专员、手册编写人员或者文案专员编制软件产品附带的文件和联机文档
结构管理员和制作人员负责把程序员编写的全部文档资料合成为一个软件包
软件开发模式
大棒式
边写边改式
流水式
螺旋式
第三章 软件测试的实质
测试原则
完全测试程序是不可能的： 输入量太大，输出结果太多，软件实现途径太多，软件说明书没有客观标准，从不同的角度看，软件缺陷的标准不同
软件测试是有风险的行为：软件测试员要学会一个主要原则是如何把无边无际的可能减少到可以控制的范围，以及如何针对风险制定做出明智抉择，去粗存精
测试无法显示潜伏的软件缺陷
找到的软件缺陷越多，就说明软件缺陷越多
并非所有软件缺陷都能修复
不要修复软件缺陷的原因如下：
没有足够的时间
不算真正的软件缺陷
修复的风险太大
不值得修复难以说清的软件缺陷
产品说明书不断变化
软件测试员在产品小组中不受欢迎
软件测试是一项讲究条理的技术专业
软件测试的术语
- 精确和准确
- 验证和合法性检查
验证是保证软件符合产品说明书的过程；合法性检查是保证软件满足用户要求的过程 - 质量和可靠性
如果说软件产品的质量高，就是指它能够满足客户要求，可靠性只是质量的一个方面 - 测试和质量评判（QA）
软件测试员的目标是找出软件缺陷，尽可能早一些，确保得以修复
软件质量评判人员的主要职责是创建和加强促进软件开发并防止软件缺陷的标准和方法
第四章 检查产品说明书
确保最终产品符合客户要求以及正确计划测试量的唯一方法是在产品说明书中完整描述产品
编写详细产品说明书的另一个好处是软件测试员可以将其作为测试项目的书面材料
黑盒子和白盒子测试
在黑盒子测试中，软件测试员只需知道软件要做什么即可–而无法看到盒子中是如何运作的
在白盒子测试中，软件测试员可以访问程序员的代码，并通过检查代码来协助测试– 可以看到盒子里面。测试员根据代码检查结果判定多大的数字可能出错，并据此调整测试程序
静态和动态测试
静态测试是指测试不运行的部分–只是检查和审阅
动态测试是指通常意义上的测试–运行和使用软件
静态黑盒子测试，测试产品说明书
测试产品说明书属于静态黑盒子测试。
对产品说明书进行高度审核
1.设身处地为客户着想
2.研究现有标准和规范
公司惯用语和约定
行业要求
国家标准
图形用户界面
硬件和网络标准
3.审查和测试同类软件
审查竞争产品时要注意的问题包括：
规模
复杂性
测试性
产品说明书的低级测试技术
1.产品说明书属性检查清单
完整
准确
精确、不含糊、清晰
一致
贴切
合理
代码无关
可测试
2.产品说明书用语检查清单
总是、每一种、所有、没有、从不
当然、因此、明显、显然、必然
某些、有时、常常、通常、惯常、经常、大多、几乎
等等、诸如此类、依此类推
良好、迅速、廉价、高效、小、稳定
已处理、已拒绝、已忽略、已消除
如果…那么…
第五章 闭着眼睛测试软件
1.动态黑盒子测试
不深入代码细节的软件测试方法称为动态黑盒子测试，常常被称为行为测试
- 软件测试由两个基本方法：通过测试和失败测试。
在进行通过测试时，实际上是确认软件至少能做什么，而不会考验其能力。
在设计和执行测试案例时，总是首先进行通过测试。在破坏性试验之前看看软件基本功能是否实现是很重要的，否则在正常使用软件是就会奇怪为什么有那么多软件缺陷。
为了破坏软件而设计和执行的测试案例称为失败测试或迫使出错测试。
3.等价分配
选择测试案例的方法是等价分配，又是称为等价划分。等价分配是指分步骤地把过多的测试案例减少到同样有效的小范围的过程
等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例
在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间
4.数据测试
软件由两个最基本的要素组成：数据和程序
对数据进行软件测试，就是在检查用户输入的信息、返回结果以及中间计算结果是否正确
根据下列主要原则进行等价分配，以合理减少测试案例：边界条件、次边界条件、空值和无效数据
（1）边界条件
边界条件是指软件计划的操作界限所在的边缘条件
（2）边界条件类型
（3）测试边界线
提出边界条件时，一定要测试临近边界的合法数据，即测试最后一个可能的合法的数据，以及刚超过边界的非法数据
在软件的每一个部分不断寻找边界是极为重要的，更多的边界将会被发现，从而找出更多软件缺陷
有些边界在软件内部，最终用户几乎看不到，但是软件测试仍有必要检查。这样的边界条件成为次边界条件或者内部边界条件
例子：2的乘方和ASCII表
一定要考虑建立处理默认值、空白、空值、零值或者无输入等条件的等价区间
数据测试的最后一种类型是垃圾数据。
5.状态测试
软件状态是指软件当前所处的情况或者模式
软件测试员必须测试程序的状态及其转换
（1）测试软件的逻辑流程
对于软件测试，解决方法是运动等价分配结束选择状态和分支
（2）简历状态转换图
状态转换图应该包含以下项目：
软件可能进入的每一种独立状态，这里有一个很好的大拇指规则是：如果不能断定是否为独立状态，它就可能是，如果以后发现不是，随时可以将其剔除
进入或退出某种状态时的设置条件及输出结果
因为正在进行黑盒子测试，所以不必了解代码中设计的底层变量。从软件用户的角度建立状态图即可
（3）减少要测试的状态及转换的数量
正如对数据等价分配一样，大量的可能性也需要减少到可以操作的测试案例集合。方法有以下5种：
每种状态至少访问一次。无论用什么方法，每一种状态都必须测试
测试看起来最常见最普遍的状态转换
测试状态之间最不常用的分支
测试所有错误状态及其返回值
测试随机状态转换
（4）怎么进行具体测试
6.失败状态测试
（1）竞争条件和时序错乱
以下是要面临竞争条件的典型情形：
两个不同的程序同时保存或打开同一个文档
共享同一台打印机、通讯端口或者其他外围设备
当软件处于读取或者修改状态时按键或者单击鼠标
同时关闭或者启动软件的多个实例
同时使用不同的程序访问一个共同的数据库
（2）重复、压迫和重负
重复测试是不断执行同样的操作，进行这种反复测试测主要原因是看内存是否不足。
压迫测试是使软件在不够理想的条件运行–内存小、磁盘空间少、CPU速度慢、调制解调器速率低等等。观察软件对外部资源的要求和依赖的程度，目的在于尽可能滴限制软件的必要条件。
重负测试和压迫测试相反，重负测试是尽量提供条件任其发挥。
对于重复、压迫和重负测试有两个重要事项：
项目管理员和小组程序员可能不完全接收软件测试员这样打破软件的做法
无数次打开和关闭程序对于手工操作时不可能的
7.其他黑盒子测试技术
（1）像愚笨的用户那样做
（2）在已经找到软件缺陷的地方再找找
（3）凭借经验、直接和预感
第六章 检查代码
1.静态白盒子测试：检查设计和代码
白盒子测试是指访问代码，能够查看和审查
静态白盒子测试是在不执行的条件下有条理地仔细审查软件设计、体系结构和代码，从而找到软件缺陷的过程。有时称为结构分析
2.正式审查
正式审查是进行静态白盒子测试的过程
正式审查有4个基本要素：
确定问题
遵守规则
准备
编写报告
3.编码标准和规范
有三个重要的原因要坚持标准和规范：
可靠性
可读性/维护性
移植性
4.通用代码审查清单
（1）数据引用错误
数据引用错误是指使用末经正确初始化用法和引用方式的变量、常量、数组、字符串或记录而导致的软件缺陷
是否引用了末初始化的变量
数组和字符串的下标是整数值吗
在检索操作或者应用数据下标时是否包含“丢掉一个”这样的潜在错误
是否在应该使用常量的地方使用了变量
变量是否被赋予不同类型的值
为引用的指针分配内存了嘛
一个数据结构是否在多个函数或者子程序中引用，在每个引用中明确定义结构了嘛
（2）数据声明错误
数据声明软件缺陷产品的原因是不正确地声明或使用变量和常量
所有变量都赋予正确的长度、类型和存储类了嘛？
变量是否在声明的同时进行了初始化
变量有相似的名称嘛
存在声明过、但从末引用或者只引用过一次的变量嘛
在特定模块中所有变量都显示声明了嘛
（3）计算错误
计算或者运算错误时基本的数学逻辑问题
计算中是否使用了不同数据类型的变量
计算中是否使用了不同数据类型相同但不同长度的变量
计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则
赋值的目的变量是否小于赋值表达式的值
在数值计算过程中是否可能出现溢出
除数/模是否可能为零
对于整形算术运算、某些计算，特别是除法的代码处理是否会丢失精度
变量的值是否超过有意义的范围
对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级对吗？需要加括号使其清晰嘛？
（4）比较错误
小于、大于、等于、不等于、真、假。比较和判断错误很可能是边界条件问题
比较得正确嘛
存在分数或者浮点值之间的比较嘛
每一个逻辑表达式都正确表达了嘛
逻辑表达式的操作数是逻辑值嘛
（5）控制流程错误
控制流程错误的原因是编程语言中循环等控制结构末按预期方式工作。
如果程序包含begin…end和do…while等语句组，end是否对应
程序、模块、子程序和循环能否终止
可能存在永远不停的循环嘛？
循环可能从不执行啊
如果程序包含想swithc…case语句这样的多个分支，索引变量能超出可能的分支数目嘛
是否存在“丢掉一个”错误，导致意外进入循环
（6）子程序参数错误
子程序参数错误的来源是软件子程序不正确的传递数据
子程序接收的参数类型和大小与调用代码发送的匹配嘛
如果子程序有多个入口点，引用的参数是否与当前入口点没有关联？
常量是否当做形参传递，意外在子程序中改动？
子程序是更改了仅作为输入值的参数？
每个参数的单位是否与相应的形参匹配
如果存在全局变量，在所有引用子程序中是否有相似的定义和属性
（7）输入/输出错误
输入/输出错误包括文件读取、接收键盘或者鼠标输入以及向打印机或者屏幕输出设备写入数据
软件是否严格遵守外部设备读写数据的专用格式
文件或者外设不存在或者末准备好的错误情况又处理嘛
软件是否处理外部设备末连接、不可用、或者读写过程中存储空间占满等情况
软件以预期方式处理预计的错误嘛？
检查错误提示信息的准确性、正确性、语法和拼写了吗
（8）其他检查
软件是否使用其他外语？是否处理扩展ASCII字符，是否需要用统一编码取代ASCII
软件是否要移植到其他编译器和CPU，具有这样做的许可嘛？如果没有计划或者测试，那么，移植性可能成为一个大难题
是否考虑了兼容性，以使软件能够运行在不同数量的可用内存，不同的内部硬件
程序编译是否产生“警告”或者“提示”信息
第七章 带上X光眼镜检查软件
1.动态白盒子测试
动态白盒子测试是指利用查看代码功能和实现方式得到的信息来确认哪些要测试，哪些不要测试，如何开展测试。
动态白盒子测试不仅仅是查看代码，还包括直接测试和控制软件。动态白盒子测试包括以下4个部分：
直接测试底层功能、过程、子程序和库（API）
以完整程序的方式从顶层测试软件，但是根据对软件运行的了解调整测试案例
从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以正常测试难以实现的方式运行
估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的，补充遗漏的
2.动态白盒子测试和调试
动态白盒子测试的目标是寻找软件缺陷，调试的目标是修复他们。
3.分段测试
从测试的角度看，产生高额费用有如下两个原因：
难以甚至不可能找到导致问题的原因
某些软件缺陷掩盖了其他软件缺陷
（1）单元和集成测试
从底层进行的测试称为单元测试或者模块测试。等到单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块组进行集成测试
这种递增测试有两条途径：自低向上和自顶向下。
在自低向上测试中要编写称为测试驱动的模块测验正在测试的模块。测试驱动模块以将来真正模块同样的方式挂接，向处于测试的模块发送测试案例数据，接收返回结果，验证结果是否正确。
自顶向下测试有点像小规模的大棒测试。
4.数据范围
合理的方法是像黑盒子测试那样把软件分成数据和状态，从同样的角度看待软件，可以轻松的把得到的白盒子信息映射到已经写完的黑盒子案例
首先考虑数据、数据包括所有的变量、常量、数据、数据结构、键盘和鼠标输入、文件、屏幕输出/输入，以及调制调解器、网络等其他设备的输入/输出
（1）数据流
数据流范围主要是指在整个软件中跟踪一批数据
（2）次边界
（3）公式和等式
（4）错误强制
使用错误强制的上好方法是迫使软件中的所有错误提示信息显示出来
5.代码的范围
代码范围分析属于一种动态白盒子测试，因为在它要求通过完全访问代码查看运行测试案例时经过哪些部分
代码范围分析最简单的形式是利用编译环境的调试器通过单步执行程序查看代码
（1）程序语句和代码行范围
代码范围最直接的形式成为语句范围或者代码行范围
（2）分支范围
试图覆盖软件中所有路径成为路径测试。路径测试最简单的形式成为分支范围测试
（3）条件范围
条件范围测试将分支语句的附件条件考虑在内
小结：
静态黑盒子测试是指检查产品说明书，并在投入软件编写之前查找问题
动态黑盒子测试是指在不了解软件如何工作的前提下进行测试
静态白盒子测试是指通过正式审查和检验检查代码的细节
动态白盒子测试是只在看到软件的工作方式时，根据获得的信息对软件进行测试
第三部分 运动测试技术
第八章 配置测试
- 配置软件综述
（1）分离配置缺陷
判断缺陷是配置问题而不仅是普通缺陷最可靠的方法是，在另一台有完全不同配置的计算机上一步步执行导致问题的相同操作。如果缺陷没有产生，就极有可能是配置问题。如果缺陷在多种配置中出现，就可能只有普通缺陷
软件可能包含在多种配置中都会出现的缺陷
软件可能包含只在某一种特殊配置中出现的缺陷
硬件设备或者其设备驱动程序可能包含仅由软件揭示的缺陷
硬件设备或者其设备驱动程序可能包含借助许多其他软件才能看出的缺陷–尽管它可能对测试的软件业很明显
（2）计算工作量
2.执行任务
（1）确定所需要的硬件类型
（2）确定哪些硬件商标、型号和驱动程序可用
（3）确定可能的硬件特性、模式和选项
（4）将明确后的硬件配置缩减为可控制范围
（5）明确使用硬件配置的软件唯一特性
（6）设计在每一种配置中执行的测试案例
（7）在每种配置中执行测试
（8）反复测试直到小组对结果满意为止
3.获得硬件
只买可以活着将会经常使用的配置
与硬件生成厂商联系
向全公司的人发送演示版或者电子邮件
（1）明确硬件标准
（2）对其他硬件进行配置测试
第九章 兼容性测试
- 兼容性测试综述
软件兼容性测试是指检查软件之间是否正确地交互和共享信息。
如果受命对新软件进行兼容性测试，就需要解答以下问题：
软件设计要求与何种其他平台和应用软件保持兼容？如果要测试的软件是一个平台，那么设计要求什么应用程序在其上运行
应该遵守何种定义软件之间交互的标准或者规范？
软件使用何种数据与其他平台和软件交互和共享信息？ - 平台和应用程序版本
（1）向前向后兼容
向后兼容是指可以使用软件的以前版本。向前兼容是指可以使用软件的未来半吧
（2）测试多个版本的影响
在开始兼容性测试任务之前，需要对所有可能的软件组合等价分配，使其成为验证软件之间正确交互的最小有效集合
3.标准和规范
如何进行实际测试，第一步应该是研究可能适用于软件或者平台的标准和规范。
高级标准是产品普遍遵守的规章。低级标准是本质细节。
（1）高级标准和规范
（2）低级标注和规范
5.数据共享兼容性
第十章 外国语言测试
第十一章 易用性测试
易用性是交互实用性、实用性和有效性的集中体现
1.用户界面测试
2.优秀UT由什么构成
优秀UI常见的7个要素：
符合标准和规范
灵活性
正确性
直观性
舒适性
实用性
一致性
第十二章 测试文档
1.软件文档的类型
每个软件不一定非要有所有这些部分，但是可能会有：
包装文字和图形
市场宣传材料、广告以及其他插页
授权/注册登记表
EULA 最终用户许可协议
标签和不干胶条
安装和设置指导
用户手册
联机帮助
指南、想到和CBT
样例、示例和模板
错误提示信息
2.文档测试的重要性
如果安装指导有误，或者不正确的错误提示信息吧用户引入歧途，他们就会认为这是软件缺陷—软件测试员应该发现
好的软件文档以下述3种方式提高产品的整体质量：
提高易用性
提高可靠性
降低支持费用
3.审查文档时要找什么
4.文档测试的实质
以下这些问题可以称为文档测试的实质：
文档常常得不到足够的重视、预算
编写文档的人可能不对软件是什么不甚了了
印刷文档制作要花不少时间，也能是几周，甚至几个月
第十三章 网站测试
网站测试囊括许多领域，包括配置测试、兼容性测试、易用性测试、文档测试，假如网站是全球范围的，还包括本地化测试。当然，黑盒子、白盒子、静态和动态测试都要用上
- 网站基础
部分特性包括：
不同大小、字体和颜色的文字
图形和招聘
超级链接文字和图形
不断变化的广告
下拉式选择框
用户输入数据的地方
大量功能也不那么明显，使网站更加复杂的特性如下：
可自定义的布局，允许用户更改信息在屏幕上的位置
可自定义的内容，允许用户选择想看的新闻和信息
动态下拉选择框
动态变化的文字
取决于屏幕分辨率的动态布局和可选信息
与不同网络浏览器、浏览器版本。以及硬件和软件平台的兼容性
大量增加网页易用性的隐藏格式、标记和嵌入信息 - 黑盒子测试
最容易的起始点是把网站或者整个网站当作一个黑盒子，不知道它如何工作，没有说明书，只是面对要测试的网站。查找的对象是什么呢
（1）文字
（2）超级链接
（3）图形
（4）表单
（5）对象和其他零碎功能
3.灰盒子测试
灰盒子测试是黑盒子和白盒子测试的结合，把黑盒子测试和白盒子测试的界限打乱了，仍然把软件当做黑盒子来测试，但是通过简单查看软件内部工作机制作为补充
网页非常适合进行灰盒子测试。
4.白盒子测试
真正找出重要软件缺陷的潜在复杂性要求对网站的系统结构和编程有一定的了解：
动态内容
数据库驱动的网站
用编程方法创建的网页
服务器性能和加载
安全性
- 配置和兼容性测试
配置测试是用各种软件和软件平台以及不同设置检查软件操作的过程。兼容性测试是用其他软件检查软件操作的过程
加入要测试一个网站，需要考虑可能会影响网站操作和外观的硬件和软件配置。
硬件平台
浏览器软件和版本
浏览器插件
浏览器选项
视频分辨率和色深
文字大小
调制解调器速率 - 易用性测试
遵守和测试一些基本规则有助于使网站更加易用
第四部分 加强测试
第十四章 自动测试和测试工具
1.自动化和工具的好处
工具和自动化的主要属性是：
速度
效率
准确度和精确度
坚持不懈
2.测试工具
如果工具仅用于监视和检查软件而不对其进行修改，就可以认为是非侵入式。然而，如果工具以任何方式修改程序代码或者操作系统环境，就属于侵入式。
（1）查看器和监视器
（2）驱动程序
驱动程序时用于控制和操作测试软件的工具。驱动程序最简单的例子是批文件
（3）管道
管道与驱动程序对立之处是不控制或者操作测试软件；相反，它接收或者响应软件发送的数据。
（4）施压和增负工具
施压和增负工具向测试软件增加压力和负荷
（5）干扰发射器和噪声发生器
（6）分析工具
3.软件测试自动化
（1）宏录制和回放
（2）可编程的宏–在简单录制和回放基础上的变革
（3）完全可编程的自动测试工具
4.随机测试：猴子测试员
5.使用测试工具和自动化的实质
在开始使用所述技术之前，应该对一些可能使其难以使用的重要问题加以考虑：
软件变更
人眼和直觉是不可替代的
验证难以实现
容易过分依赖自动化
不要花费太多时间使用达不到测试软件目的的测试工具和自动化
编写宏、开发工具和编制猴子都属于开发工具
某些工具是侵入式的
好好想一想需要执行的测试任务，如何利用软件使其更加容易和快速实现—这正是自动化的领域
第十五章 臭虫轰炸和beta测试
1.能看多远看多远
请其他人检查软件有足浴打破杀虫剂怪现象
类似地，人们不仅相互之间看到的不同，而且测试方法也不同
有人帮忙测试有助于消除烦躁信息
观察别人解决问题的方式是学习新测试技术的好方法
2.测试共享
一个常用的方法是在一定时间内简单互换测试任务。
共享测试任务的有趣方法是安排臭虫轰炸，臭虫轰炸是在一段时间内整个测试小组停下指定的常规测试任务，参加轰炸。
请求协助寻找软件缺陷的最佳伙伴是产品支持或者客户服务小组
3.Beta测试
另一种让他人验证和证实软件的常用方法称为Beta测试
Beta测试是用于描述外部测试过程的属于，在该过程中，软件分发给选定潜在客户群，他们在实际环境中使用软件。Beta测试一般在产品开发周期行将结束时进行，理想情形下指示证实准备向实际客户发布的软件
从测试角度看，在计划或者依赖Beta测试时，有几个问题需要考虑
谁是Beta测试者
同样，怎么知道Beta测试者使用过软件
Beta测试对其有所助益的另一个领域是易用性测试，条件是精心挑选参加者–有经验的用户和无经验的用户完美结合
撇开配置、兼容性和易用性，Beta测试在寻找软件却行方面竟然出人意料地差。
Beta测试程序会耗费测试员大量时间
4.提交测试
第五部分 使用测试文档
第十六章 计划测试工作
1.测试计划的目标
软件测试文档的ANSI/IEEE标准829/1983以如下方式表达软件测试计划的目的：规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险。
测试计划只是制作产品的详细计划过程的副产品，重要的是计划过程，而不是产生的文档。
测试计划过程的最终目标是交流软件测试小组的意图、期望，以及对将要执行的任务的理解
2.测试计划主体
（1）高级期望
测试计划过程和软件测试计划的目的是什么？
测试的是什么产品？
产品的质量和可靠性目标是什么？
（2）人、地点和事
测试计划需要明确在项目中工作的人，他干什么，怎么和他联系。同样，文档存放在哪里，软件从哪里可以下载，测试工具在哪里等等都需要明确
（3）定义
以下是一些常用术语和相当松散的定义
构造
测试发布文档（TRD）。程序员发布的文档，其中每一个构造文件都声明新特性、不同特性、修复问题和准备测试的内容
Alpha版。意在对少数主要客户和市场进行数量有限的发布，用于演示目的的早期构造
Beta版。意在向潜在客户广泛发布的正式构造
说明书完成。
特性完成
软件缺陷会议
（4）团队之间的责任
团队之间的责任是明确指出可能影响测试量的任务和交付内容。
（5）哪些要测试，哪些不要测试
（6）测试阶段
（7）测试策略
（8）资源要求
人员
设备
办公室和实验室空间
软件
提交测试公司
其他供应
（9）测试员任务分配
（10）测试进度
使测试任务摆脱危机的一个方法是测试进度避免定死启动和停止任务的日期
（11）测试案例
（12）软件缺陷报告
（13）频度和统计
频度和统计是跟踪项目进展、成效和测试的手段，测试计划过程应该明确收集哪些信息，要做什么决定吗，谁来负责收集
使用测试频度的例子如下：
在项目期间每天发现的软件缺陷总数
仍然需要修复的软件缺陷清单
根据严重程度对当前软件缺陷评级
每个测试员找出的软件缺陷总数
从每个特性或者区域发现的缺陷数目
（14）风险和问题
软件测试员要负责明确指出计划过程中的风险，并与测试管理员和项目管理员交换意见。
第十七章 编写和跟踪测试案例
1.测试案例计划的目标
有条不紊地仔细计划测试案例，是达成目标的必由之路
组织性
重复性
跟踪
测试证实
2.测试案例计划综述
（1）测试设计
ANSI/IEEE 829称测试设计说明为“提炼测试方法，明确指出设计包含的特性及其相关测试。如果要求完成测试还明确指出测试案例和测试程序，指定特性通过/失败的规则”
测试设计说明的目的是组织和描述针对具体特性需要进行的测试
作为测试设计说明的部分内容：
标示符。用于引用和定位测试设计说明的唯一标示符
要测试的特性
方法，用于测试特性的通用方法描述
测试案例论证。对用于检查特性的具体测试案例的高级描述和引用
通过/失败规则
（2）测试案例
ANSI/IEEE 829称测试案例说明为“编写用于输入输出的实际数值和预期结果。测试案例还明确指出使用具体测试案例产生的测试程序的任何显示”
测试案例细节基本上应该解析要向软件发送什么值或者条件，以及预期结果。它可以由多个测试案例说明来引用，也可以引用多个测试程序。还列出了其他包括在内的重要信息：
标识符。由测试设计过程说明和测试程序说明引用的唯一标识符
测试项。描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体。
输入说明
输出说明
环境要求是指执行测试案例必要的硬件、软件、测试工具、实用工具、人员等等
特殊要求
案例之间的依赖性
（3）测试程序
测试程序说明为“明确指出为实现相关测试设计而操作软件系统和试验具体测试案例的全部步骤”
以下为需要定义的内容：
标识符
目的
特殊要求
程序步骤
日志
设置
启动
程序
衡量标准
关闭
终止
重置
偶然事件
（4）细节和真实
3.测试案例组织和跟踪
在建立测试案例文档时应该考虑一个问题是如何组织和跟踪信息
计划执行哪些测试案例？
计划执行多少个测试案例？执行需要多少时间？
能否挑选出测试套装测试某些特性或者软件部分？
在执行测试案例时，能够记录哪一个通过，哪一个失败？
在失败的测试案例中，哪些在上次执行时也失败了？
上次执行测试案例时通过的百分比是多少？
管理和跟踪系统基本上有以下4种：
凭脑子记
书面文档
电子表格
自定义数据库
计划测试案例的4个原因：组织性、重复性、跟踪和测试证实
第十八章 报告发现的问题
1.使软件缺陷得以修复
软件测试中发现的大多数软件缺陷不会这样戏剧化，要求简洁、清晰地把发现的问题传达给判断修复/不修复的小组，使其得到所需的全部信息决定怎么做。
报告软件缺陷的基本原则：
尽快报告软件缺陷
有效描述软件缺陷
有效的软件缺陷描述如下所示：
短小
单一
明显和通用
再现
在报告软件缺陷时不做评价
补充完善软件缺陷报告
2.分离和再现软件缺陷
不存在随机软件缺陷这样的事–如果建立有绝对相同输入的绝对相同条件，软件缺陷就会再次出现。然而验明和建立有绝对相同输入的绝对相同条件要求技巧性非常高，而且非常耗时。
如果找到的软件缺陷似乎要采用繁杂步骤才能再现，或者根本无法再现，如下一些提示和技巧会打开局面
不要想当然地接收任何假设。几下所做的每一件事，每一个步骤、每一次停顿，每一件工作
查找时间依赖和竞争条件的问题
与压迫和负荷相关的边界条件软件缺陷、内存泄露和数据溢出等白盒子问题也许慢慢自己显露出来
状态缺陷仅在特定状态中显露出来
考虑资源依赖性和内存、网络、硬件共享的相互作用
不要忽视硬件
3.所有软件缺陷不是生来就平等的
在每一个软件工程中必须进行取舍，承担一定的风险，以决定哪些软件缺陷需修复，哪些不修复，哪些推迟到软件的以后版本中解决
测试员要对软件缺陷分类，以简明扼要的方式指出其影响。常用的方法是给软件缺陷划分严重性和优先级。通用原则如下：
严重性表示软件缺陷的恶劣程度，反映其对产品和用户的影响
优先级表示修复缺陷的重要程度和应该何时修复
严重性：
系统崩溃、数据丢失、数据毁坏
操作性错误、错误结果、遗漏功能
小问题、错别字、UT布局、罕见故障
建议
优先级：
立即修复、阻止进一步测试、立竿见影
在产品发布之前必须修复
如果时间允许应该修复
可能会修复，但是也能发布
4.软件缺陷的生命周期
5.软件缺陷跟踪系统
（1）标准：测试事件报告
ANSI/IEEE 829标准定义了一个称谓测试事件报告的文档，其目的是“编写在需要调查研究的测试过程期间发生的任何时间”简而言之，就是等级软件缺陷
审查标准是提取当前已经掌握的软件缺陷报告信息，以及把它们全部放在一起观察结果的好方法。下列清单列出了标准定义的范围，采用时做了一点更新以反映新出现的术语：
标示符：软件缺陷报告的唯一ID
总结：测试的软件及其版本的引用信息、相关的测试程序、测试案例和测试说明也应该包含在内
事件描述。用下列信息详细描述软件缺陷：日期和时间；测试员的姓名；使用的硬件和软件配置；输入；程序步骤；预期结果；实际结果；试图再现以及尝试的描述；有助于程序员定位软件缺陷的其他现象或者信息
影响，严重性和优先级，以及测试计划、测试说明、测试程序和测试案例的影响指示
（2）手工软件缺陷报告和跟踪
（3）自动软件缺陷报告和跟踪
第十九章 评价成效
用于描述软件项目特性属性度量单位的术语是软件频度，每天每个测试员发现软件缺陷的平均数是频度。从每个区域发现软件缺陷的数目是频度。严重性1软件缺陷与严重性4软件确定的比率也是频度
第六部分 软件测试展望
第二十章 软件质量评判
1.质量是免费的
